ElastiCache for Redis サービス更新適用時のダウンタイムを調べてみた

ヘヴィメタルとBABYMETALをこよなく愛するCX事業本部 久保田です。

運用中のElastiCache for Redisにサービスの更新（security-update）が提供されていたため適用することになりましたが、適用中にダウンタイムがどれくらいあるのか気になったので手順確認と合わせて検証してみました。

検証環境

• ノードタイプ: cache.t2.micro
• ノード数: 2
• エンジンバージョン: 3.2.10
• 自動フェールオーバー: enabled
• マルチAZ: enabled
• データサイズ: 約4MB

検証方法

今回検証に利用した環境はキャッシュサーバーへのリクエストが失敗してもリカバリーが可能な構成となっておりそれほどシビアな要件を求められていないため、以下の内容でスクリプトを作成しました。

• 1秒ごとにデータを読み書きし続ける
• エラー発生時に時間とエラー内容を出力する

検証実施

サービス更新の適用前に連続リクエストするスクリプトを実行しておきます。

ElastiCacheダッシュボードの上の方に通知されている[今すぐ更新]ボタンを押します。

更新を行いたいクラスターを選択して[確認ボタン]を押します。 1ノードあたり30分程度かかると推測されています。

[ステータスを更新]列を見るとwaiting-to-startからin-progressに変わります。

適用中にノード一覧画面で更新ボタンをポチポチ押しているとレプリカだったノードがプライマリーに昇格しました。 ダウンタイムを少なくするためにレプリカから適用されているのだと思われます。

また、このタイミングで実行していたスクリプトで書き込みエラーのログが出力されました。（結果はのちほど）

またしばらく待つと[ステータスを更新]列がcompleteになりました。

[ステータス]、[パラメーターグループのステータス]列ともに正常で無事完了したようです。

検証結果まとめ

1ノードあたり約30分という推測がされていましたがデータ量が少なかったことも関係するのかサービス適用の開始から終了までの総時間は約12分でした。 このうち、ダウンタイムがどれくらいだったのかを実行していたスクリプトのログで確認した結果が以下となります。

• 読み取りエラー: 0回
• 書き込みエラー: 7回（秒）
  • エラー内容は全て READONLY You can't write against a read only slave.

書き込みエラーになったのは連続7回でプライマリー、レプリカが入れ替わるタイミングだけのようでした。 読み取りエラーは0回でしたが、リクエスト間隔がもっと短い場合は違った結果になるかもしれません。

リクエスト間隔以外にもノードタイプ、ノード数、設定しているパラメーター、データサイズなどによってサービス適用時間やダウンタイムは変わってくる可能性がありますので、ご利用の環境やシステム要件に沿ったダウンタイム検証を行うことをお勧めします。